An OLAP Requirements Example: CompSales International (part 11)

Calculated Members (Calculations)

Remember from the Comp Sales requirements that there was an additional user need to see the difference between sales units and sales returns (sales units minus sales returns) to yield net sales. One approach is to use the SSAS calculated members (calculations) capability. This creates an expression against existing measures that will be treated the same as a measure. Basically, you need to complete the requirements for the Comp Sales cube by adding a calculation measure to this cube for net sales units.

To create a calculation, you go back to Visual Studio and the cube designer. Then you click the Calculations tab and create a new calculation measure called Sales Units NET with the calculation expression of (Sales Units - Sales Returns), as shown in Figure 46. Many functions are available for use that should meet your individual calculation needs.

Figure 46. A new calculation measure of Sales Units NET in the Visual Studio cube designer.

This calculation fulfills the data measure requirements of Comp Sales. All that is left to do is to process the cube so others can use it. The following sample MDX query uses the newly created calculation measure:

WITH MEMBER [Measures].[Total Sales Units NET]
         AS 'Sum([Measures].[Sales Units NET])'
SELECT
     {[Measures].[Total Sales Units NET]} ON COLUMNS,
     {Topcount([Product_Dimension].[SKU].members,100,
                       [Measures].[Total Sales Units NET])}
     ON ROWS
FROM [Comp Sales]
WHERE ([Time_Dimension].[All Time])

Figure 47 shows this new calculation measure listed in the cube’s metadata pane. You can see how easy it is to use in the cube data browser. You might want to check the math, however, to make sure the calculation is correct.

Figure 47. Data browsing using the Sales Units NET calculation in the Visual Studio cube designer data browser.

Query Analysis and Optimization

In SSAS, you can look at query utilization and performance in a cube. You can look at queries by user, frequency, and execution time to determine how to better optimize aggregations. If a slow-running query is used frequently by many users, or by the CEO, it might be a good candidate for individual tuning. A usage-based analysis capability can be used to change aggregations based on actual live queries that the cube must service. This adjusts aggregations based on a query to reduce response time. You start this wizard by right-clicking the cube’s partition. Figure 48 shows the Usage-Based Optimization Wizard splash page.

Figure 48. The Usage-Based Optimization Wizard.

The Usage-Based Optimization Wizard allows you to filter queries by user, frequency of execution, time frame, and execution time. You see a record for each query you have run since the date you began, the number of times it was executed, and the average execution time, in seconds. This is like a SQL trace analysis of your OLAP queries.

Because aggregations already exist, the wizard asks whether you want to replace them or add new ones. If you replace the existing aggregations, the cube is reprocessed with this particular query in mind.